With the advent of highly sophisticated computer software/hardware, various computational servicing areas have been created to meet a myriad of consumer demands. Typically, computational services are undertaken upon a client or within a proprietary intranet. Client-side systems are generally employed to manage relationships between users, software applications, services, and hardware within a client machine, as well as data resident upon a respective intranet. In addition to client-side systems that provide services, off-site systems (e.g., third party) can also provide services in order to improve data capability, integrity, reliability, versioning, security, and mitigate costs associated therewith.
In general, such services can be employed to manage relationship between users, provide software applications, enhance hardware capabilities, manage data, optimize security, and the like. For example, a third party service can enable a client to store data solely by the third party capabilities (e.g., hardware, software, etc.) With such increase in growth related to servicing businesses, associated data may also be at risk of loss as a result of planned events (e.g., strike, closing, shut downs, etc.), or unforeseen circumstances such as, catastrophic failures, destruction, and the like.
Moreover, when required to support a large-scale user base or to provide a high-level of availability, such services are often provided in a data center using one of many service-oriented architectures (SOA). Typically, implementation of an SOA requires tools as well as run-time infrastructure software, which can collectively be referred to as SOA implementation framework. Such frameworks have unique requirements at both the tools and infrastructure levels. For example, these can include a distributed event-enabled architecture, flexibility via service-enabled processes, enterprise standards support (fault tolerance, reliability, and scalability), security in distributed environment, visual process composition/monitoring, and support for rapid process changes or process development, to enable providing new and improved user services.
Furthermore, server virtualization has become central to data center disaster recovery planning. Such server virtualization can reduce costs related to idle physical servers/data center footprint, and can further improve uptime/recovery time for matters pertaining to disaster recovery. Moreover, data integrity can further be ensured for retrieval of high-availability system management and failover. Such high-availability systems include systems or components that are continuously operational for a desirably long length of time (e.g., availability can be measured relative to “100% operational” or “never failing”), for example.
Likewise and in case of server consolidation, many small physical servers can be replaced by a larger physical server, to facilitate utilization of costly hardware resources such as CPU. Typically, even though hardware can be consolidated, operating systems (OSs) are not. Rather, each OS running on a physical server can convert to a distinct OS running inside a virtual machine. Hence, the large server can “host” many such “guest” virtual machines (e.g., a Physical-to-Virtual—P2V-transformation.)
Accordingly and as compared to a real physical machine, a virtual machine (VM) can be readily controlled and inspected from outside, and its configuration can be more flexibly maintained—wherein multiple virtual servers can run on a single physical server, to more fully utilize hardware resources thereof. Moreover, depending on type of virtualization software employed, a virtual machine can further be duplicated and installed on multiple hosts.
Nonetheless, tracking a state of a virtual machine as a whole, and checkpoint migration for a state of the VM (including its OS) can cause excessive overhead in terms of both network bandwidth and required computing cycles. Furthermore, delays associated with such procedures can become unacceptable for various applications, such as real-time media. Similarly, application-based checkpointing processes typically do not account for associated overheads (e.g., related to additional virtualization layers), and can encounter substantially high delays and additional computing cycles.